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Tnfrrnfliint.]ftn 

Ihe  area  ot  knowledge  representation  n6is  received  active 
research  interest  recently  as  more  powertul  knowledgeHiased 
systems  have  been  developed.  Such  systems  show  potential  in 
several  e^ipllcation  areas,  including  database  management  systems, 
decision  support  systems,  and  automatic  programning  systems.  A 
variety  or  techniques  tor  knowledge  representation  nave  been 
eiqpiored;  one  or  tne  more  promising  is  tne  use  ot  resolution 
logic. 

Among  the  many  problems  which  must  be  resolved  betore  such 
approaches  can  be  used  in  production  systems  is  that  or  search 
etticiency.  Current  systems  either  handle  a  variety  ox  problem 
structures  at  the  cost  ot  relatively  unconstrained  search  or 
constrain  search  at  the  cost  ot  rigidly  detined  problem 
structures.  An  additioneu.  seardi  problem  results  trom  tne  need 
to  expand  the  current  small  systems,  which  are  primarily  in-core 
systems,  to  much  larger  size. 


2.  Prolog 


Prolog  is  a  programming  language  based  iqpcxi  tne  use  ot 
resolution  logic  which  provides  a  high  level  nonprocedural 
mechanism  tor  writing  programs  and  representing  data.  Ohe  Prolog 
language  is  described  in  Warren  Al  (1977) ,  and  tne  underlying 
logical  theory  is  described  in  Kowalski  (1974)  and  Robinson 
(1965) .  Kowalski  (1979)  provides  an  extensive  introduction  to 
logic  programming  witn  enphasis  on  Prolog. 

Ihe  basic  construct  usee  in  Prolog  is  the  clause,  wmen 
consists  ot  a  series  or  terms.  An  example  of  such  a  clause  is 


grandparent (x,y)  parent(x,z),  parent  (z,y) 


The  first  term  is  tne  nead;  tne  rest  make  up  tne  bo(^.  If 
ail  ot  the  terms  in  the  body  are  true,  then  tne  head  is  true.  A 
procedure  is  a  set  of  clauses.  A  clause  witn  an  empty  body  is 
referred  to  as  a  unit  clause.  Si^pose  tnat  tne  roiiowing  unit 
clauses  are  added  to  tne  previous  clause: 

parent  (Jim,  Jane) 


parent  (Jane,  Jennifer) 
parent  (Jane,  John) 
parent  (Joe,  John) 
parent  (Jim,  Janioe) 

[ 

i 


1 


parent  (josie,  Jane) 


Ihen  posing  the  goal  granctarent  (u,  Jenniter)  wiri  tind 
aix  or  uenniter's  gran^rents.  Posing  tne  goal  granc()arent 
(Jin,  V)  will  find  Jin's  grandcniidren.  Posing  tne  goal 
gran^pareftt  (u,  v)  wui  tina  all  ot  tne  pairs  ot  grano|arents  and 
granounudren  known  to  tne  eysten. 

Consider  tne  tirst  case  given,  tnat  ot  rinding  Jenniter 's 
granccaroits.  The  ^stem  AttxapcB  to  snow  tnat  tne  nead  is  true 
by  snowing  tnat  botn  ot  tne  clauses  parent  lu,  y)  and  parent  (y, 
Jennifer)  are  true.  (Here  x  is  zegiMoed  by  u,  and  z  is  replaced 
by  Jenniter.)  It  can  do  tnis  by  substicuung  y  >  Jane  and  u  = 
Jim  or  by  substituting  y  «  Jane  and  u  Josie.  The  process  ot 
tinding  appreciate  subetirucicxis  tor  tne  variaoies  is  reterred 
to  as  unificatiem.  The  process  ot  tinding  an  appropriate 
uiurication  mezms  traversing  a  seucb  space  witn  many  possible 
ot  Clauses  and  vari^ie  assignmotits  and  includes  tne 
possibility  ot  backtracking  it  a  particular  patn  does  not  work 
out.  It  is  also  possible  tnat  no  appco[H:iate  unincation  win  be 
round. 

The  oMHipie  given  here  is  quite  sioptle.  More  elaborate 
exanpi^  ^  round  in  tne  reterences  previously  given.  Prolog 
can  oe  used  for  a  variety  ot  icd-ications  ranging  from 
intelligent  databases  to  automatic  pcogranning  (^sterns. 


3.  Tlap 

Li^  is  a  list  oriented  language  based  ipon  tne  lanbda 
calculus.  TWO  ot  tne  many  expository  descriptions  are  given  in 
Greenberg  (1978)  and  Siklossky  (1976) .  A  brier  sumary  ot  Lisp 
developaent  is  given  in  HoLartny  (1978) .  Its  predominant  use  is 
in  artiriciai  intelligence  work. 

In  LisPr  botn  programs  and  data  are  r^esented  as  lists  and 
are  not  explicitly  distinguisned.  For  exanple,  a  (very  sinple) 
Lisp  program  to  evalate  tne  square  root  or  3.3  -t-  (4.1  x  5.2) 
could  be  written  as 

(SORT  (FFLDS  3.3  (FTIMES  4.1  5.2))) 

This  is  a  two  iten  list;  tne  seccsvi  item  is  itseit  a  list. 
Hhai  tnis  tunction  is  evaluated,  the  multiplioati(xi  in  tne  inner 
sublist  IS  evaluated  first.  Then  tne  3.3  is  added.  Finally  tne 
square  root  is  taken. 

Lisp  contains  a  variety  tmctions  and  qpecial  constructs, 
including  tnoee  tor  taking  aprt  and  putting  togetner  lists, 
testing  conditions,  and  manipulating  nusbers  and  strings. 
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Prolog  and  Liqp  are  not  equally  ea^y  to  use  over  a  lull 
range  or  a^pl-ications.  For  eatan^e,  tne  granc^rent  exanpie  used 
in  tne  discussion  ot  Prolog  would  be  nuch  harder  to  write  in  Lisp 
since  a  runction  which  explicitly  takes  «^art  uses  r^esoiting 
paroit  intomtion  would  need  to  be  written.  On  the  otner  hand, 
tne  siocae  Li^  calculation  givoi  would  be  much  harder  to  write 
in  Prolog  since  real  aritometic  and  square  roots  are  much  narder 
to  nandle  in  a  logic  context. 

Logliqp  is  a  system  wnich  ocmbines  tne  advantages  or  botn 
Prolog  and  Lisp,  It  has  been  developed  under  Air  Force 
^xxisorsnip  (RRDC)  by  Robinson  and  Sibert  (1981)  at  Syracuse 
university  as  an  extension  to  UCI  Liqp  for  tne  DBC-iu.  in  this 
language,  Li^  is  extended  to  aiilcw  tne  use  ot  logic 
progranning.  Ite  i^tax  and  techniques  are  not  quite  tne  same  as 
in  tne  Prolog  system,  but  tne  same  oasic  capabilities  are 
provided.  Ae  lisp  features  and  tne  logic  teatures  may  be 
intermixeu,  or  only  one  sec  of  teatures  may  be  used.  So  botn 
pattern  matching  (as  in  Prolog)  and  function  evaluation  (as  in 
Liq))  may  be  easily  done  in  tne  oemtext  of  an  int^rated 
language. 
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I/DGLISP  KXOABILm 


loglisp  Tirol  flirntatiog 


I/yilisp  was  originaixy  iitplemented  at  i^racuse  university;  a 
description  of  tnis  system  is  given  in  Kobinson  and  Siberc 
(1981) .  It  %«as  inplenienced  as  an  extension  to  UCI  Lisp,  a 
dialect  of  Lisp  1.6,  on  tne  KX2-10  (Quam  and  uittie,  undated; 
Bobrov,  Burton,  and  Levis,  undated) .  it  has  also  been  converted 
to  run  under  INIERLISP.  (Schrag,  1982). 


2.  The  AT.TSp  Dialect  ot  Tlsp 

ALISP  is  a  Lisp  dialect  based  on  Lisp  1.5  and  described  in 
AT.TSP  User's  Manual  (Univ.  Mass. ,  undated) .  It  was  develc^ied 
at  the  University  of  Massachusetts  at  Amherst  on  vjontrox  Data 
maintrames.  The  first  version  ran  on  a  0X2  3600/3800  under  tne 
UMASS  tiinesnaring  system.  The  current  version  runs  on  UX2  Cybers 
under  the  N36  curating  system.  In  addition  to  basic  Lisp 
features,  it  provides  a  compiler,  a  limited  progranming 
«ivir(»iment  (editor,  fixe  system,  and  pretty-printer) ,  and 
applications  packages  (reiaticxiax  database  system  cuid  graphics 
routines) . 

Since  tne  manual  proved  very  difficult  to  use  witnout  an 
index,  one  was  constructed.  It  is  given  in  i^pendix  A.  CRie 
manucU  refers  to  its  index,  but  it  was  not  present  and  couia  not 
be  located.)  Since  tne  reasabiiit^  of  conversion  from  XI  Lisp 
to  ALISP  was  being  examined,  a  oonparison  list  of  functions  was 
constructed.  It  is  given  in  Appendix  B.  This  list  snows 
functions  present  in  each  of  tne  languages  ana  includes  comnents 
on  function  similarities  and  differences.  It  can  be  seen  from 
tnis  list  tnat  tnere  are  substantial  differences  between  tne  two 
languages. 


1,.  Lisp  Dialects 

There  are  maiy  dialects  of  Lisp  in  existence.  There  nave 
been  some  efforts  at  standardization  witnin  tne  Lisp  ooRnunity, 
but  these  nave  not  met  witn  ovecwneiming  success  (e.g.  Marti  sL 
Al,  1979;  Steele  Al/  1982) .  While  tne  basic  core  of  tne 
language  is  the  same  from  dialect  to  dialect,  the  additional 
features  provided  as  part  of  tne  eystem  and  tne  manner  in  wnicn 
tne  syBtm  is  ispiemented  can  differ  widely.  such  diversity  is 
not  surprising  and  pernaps  neaitny  in  an  e;qperimmitai  language, 
but  It  nas  nampered  tne  use  of  Lisp  in  more  {»:oduction-or  rented 
environments. 

Samet  (1981)  describes  a  ocaiyersion  system  to  translate 
EMCograms  written  in  LISP  1.6  to  INIBdJSP  which  was  motivated  oy 
tne  need  to  convert  a  program  used  in  a  oonpiier  testing  system. 
The  conversion  system  was  designed  to  run  under  eitner  version  oi 


LISP.  It  depends  prinaciiy  on  pattern  substitution  tecnniques 
and  tunction  redetinitions  to  ocnvert  LISP  1.6  features  to 
MTERLISP,  including  most  tunctions,  I/O  functions,  tne  escape 
cnaracter,  strings,  names,  and  numbers.  However,  LBCPRs,  macros, 
arre^,  and  a  tew  tuncti<ms  were  excluded  from  tne  conversion 
system. 

Samet  classitied  some  problems  as  irreconcilable;  tnese 
included  mainly  problems  witn  ditrerences  in  data  type 
detinxtions.  A  woricing  definition  of  an  irreconcilable  problem 
in  tnis  context  is  one  wnich  could  not  be  handled  by  a 
straightforward  transformation  or  wnicn  could  not  be  handled 
wicnouc  run-time  support.  The  conversions  tnat  were  perrormeu 
were  divided  into  those  based  on  tne  external  form  of  tne  program 
and  tnose  based  on  tne  semantics  of  basic  constructs. 


iiu  software  Conversion  Studies 

Oonversion  or  software  developed  in  one  environment  to 
anotner  envir<xitient  is  an  in^torcant  activity  (U.S.  GAO,  1977, 
1980) .  Despite  the  extensive  resources  devoted  to  oonversion 
efforts,  little  formal  attention  nas  been  paid  to  it.  Host  or 
our  knowledge  about  software  canvetBxon  is  institutronaj.  in 
nature,  based  upon  extensive  e^qserience. 

Gilb  (1977)  defines  software  portability  as  "tne  ease  or 
oonversion  from  one  environment  to  anotner;  tne  relative 
conversion  cost  for  a  given  conversion  metxKxi  or  algoritnm."  He 
measures  portability  as  l-(En/ER),  where  ET  is  tne  cost  to 
transfer  tne  system  to  a  different  environment,  and  ER  is  the 
original  cost  ot  devel<^ing  the  software. 

This  measure  of  portability  depends  not  only  on  tne  system, 
but  also  on  tne  two  environments.  The  ooropatablity  between  tne 
two  environments  can  be  measured  as  tne  average  portabiiiiy  or 
systems  converted  from  <X)e  enviroranent  to  tne  otner.  Gilb's 
measures  provide  a  measure  ot  portability  ana  oGnpatabiiicy 
relative  to  a  population  or  tasks,  but  tney  do  not  directly 
address  tne  question  of  predicting  tne  effort  involved  witnout 
guidance  from  previous  experience  witn  tnose  systems. 

Bo^sq  (1981)  tackles  tnis  more  difficult  question  or 
estimating  tne  resources  required  for  conversion.  His  estimate 
or  oonversion  costs  is  based  on  calculating  a  value  for  ESSI, 
equivalent  delivered  source  instructions.  This  is  estimated  au> 

ES6I  «  (AD6Z)  X  (AAF/100) . 

Here  AD61  is  the  actual  delivered  source  instructions  in  tne  code 
to  be  converted,  and  AAF  is  an  adaptation  aoDUStment  factor 
calculated  as 

iiAF  -  (0.40  X  CM)  ^  (0.30  x  CM)  +  (0.30  x  IN) . 
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Here  DM  is  an  estimate  ot  tne  percent  o£  tne  design  moditled,  CM 
is  an  estimate  or  the  percent  of  lines  of  code  wich  must  be 
modified,  and  IN  is  an  estimate  or  tne  percent  ot  tne  original 
integration  and  testing  wnicn  must  be  perrocroed  on  tne  converted 
software. 

The  total  conversion  effort  in  man-montns  can  tnen  be 
estimated  as 

m  »  2.4  X  (H3SI)**1.05. 

Boehm  includes  an  extensive  discussion  or  cost  driver  factors 
wncih  can  be  usd  to  take  into  acccount  sucn  factors  as  s^sten 
ccnpLexity,  reliability  reguirements,  prograinning  language,  and 
staff  ei^rienoe. 

Obviously  these  estimates,  ei^>eciciiiy  tor  EH  and  IM,  must  be 
in  large  part  subjective.  However,  this  approach  provides  a 
structured  framework  for  the  {arobiem  of  estimating  software 
conversion  effort  wnose  worth  is  supported  by  extensive 
experience. 


Su  sageclfic  PEoblaas 

A  *'anDer  of  inocnpatability  problems  betweeen  UCI  Lisp  and 
ALISP  were  encountered.  These  were  categorized  as  environment 
incoipatabilities,  feature  inoonpatabiiities,  syntactic 
imnconpatabiiities  and  fundamental  inconpatabilities. 


The  envirormentai  inconpatabilities  included 

aiaractec  aeL 

The  character  sets  used  in  tne  two  ^sterns  are  different 
botn  in  size  and  in  encoding.  This  created  seme  delay  in  even 
reading  a  Loglisp  tape.  Furtnermore,  some  characters  used  for 
special  purposes  in  Loglisp  are  referred  to  cy  tneir  encoded 
value  (CHRVAL) . 

editor 

Both  systems  included  em  editor  as  part  of  tne  environment. 
These  allow  botn  structure  editing  suid  pattern  matching.  However, 
the  cosmands  used  are  different.  The  editor  is  used  by  Loglisp  in 
order  to  handle  editing  of  knowledge  bases.  Formatters  are 
provideu  in  botn  systems,  but  different  function  names  are  used. 

tne 

Both  dialects  of  Lisp  provide  functicms  to  allow  access  to 
tne  listens  f ue  eystcro  in  order  to  facilitate  tue  handling  witn 
tne  iJsp  eysten.  The  capabilities  provided  are  similar,  but  tne 
unueriying  file  eystens  are  not. 
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Feature  incxxnfatabilites  included 
fl£.  £unCUOD  oorrespondenoe 

There  are  many  runctions  present  in  UCI  Lisp  wnicn  nave  no 
corre^nding  tunctions  in  mLSIP.  For  cne  most  part  tnese  can  be 
nanoied  in  a  straightrorward  manner  suqpxy  by  writing  new 
runction  detinitions.  Appendix  B  contains  a  list  ot  tne 
tunctions  {xesent  in  botn  Lisp  dialects. 

marrftft 

UCI  Lisp  provides  a  macro  capability;  ALISP  does  not. 
Features  inpleniented  using  macros  tnus  need  to  be  rewritten. 

Syntactic  incompatabilites  included 

inoonaiBtmt  runction  namfts 

In  many  cases  oirrerent  names  were  used  in  tne  two  dialects 
tor  tne  same  tunction.  Examples  include  ABSVAL  (ALISP)  vs.  ABS 
(Ua  Lisp)  and  uIFF  (ALISP)  vs.  DIFFERENCE  (UCI  Lisp) .  Ohese 
proDlems  are  also  quite  straighttorward  to  nandle  by  renaming. 

inoonaistent  runction  syntax 

I  few  cases  tne  syntax  used  tor  tunctions  was  not 
consistent.  For  example,  tne  parameter  order  tor  HAPC  is 
ditterent.  Although  nandiing  tnese  situations  is 
8traignttorweu:d,  tney  are  more  subtle  since  tney  appear  correct. 

Fundamenteo.  incompatabilites  included 

handling  n£.  function  detimtions 

I  ALISP  function  detimtions  are  stored  in  tne  vaiue  oexx 
or  tne  appr<priate  literal  atoms.  In  UCI  Lisp  tunction 
detimtKxis  are  stored  on  tne  property  list.  Thus  function 
detimtions  are  easier  to  change  on  tne  tiy  in  uci  Lisp.  Since 
this  is  done  in  Loglisp  in  order  to  switch  between  Lisp  axxi 
Logic,  substantial  conversion  problems  are  presented. 

It  ehould  be  noted  tnat,  wicn  very  tew  exceptions,  tnese 
problems  are  inherent  in  tne  dialect  differences  and  are  not  due 
to  tne  design  and  impleroentation  or  oglisp.  It  would  be 
extrementiy  difficult  to  implement  a  i^stem  witn  complex 
functionality  without  making  full  use  of  tne  features  available. 


7 


Lu  language  SimiiatJLty 


The  simlLarity  between  ALISP  and  UCI  Lisp  caui  be  exananeo  by 
cxnqparing  tne  tunctions  available  in  tne  two  languages.  A  simple 
measure  of  sucn  similarity  between  two  programming  languages  is 
given  by 


SIM  =  CV  /  (H  +  N2  -  W) 

Where  Ml  is  tne  nunber  of  function  names  used  in  one  language,  N2 
is  tne  nixober  of  function  names  used  in  tne  otner  language,  and 
CV  (overlap)  is  tne  number  of  function  names  used  in  botn 
languages.  This  measure  ranges  between  0  (least  similar)  ana  1 
(most  similar) . 

There  are  a  number  of  factors  which  are  not  taken  into 
account  by  this  measure.  Function  names  xn  Lisp  and  otner 
progranming  languages  are  not  used  witn  equal  frequency,  and  tne 
most  frequent  ones  snould  pern^s  be  given  nigher  weignts.  Also, 
no  distinction  is  made  between  a  function  name  used  for  a 
function  present  in  one  language  but  not  tne  otner  and  a  runcxion 
name  used  for  a  func:tion  which  is  present  in  botn  languages  but 
called  fy  different  names. 

There  are  303  function  names  tor  UCI  Lisp  ano  227  tor  aLISP; 
tnese  are  given  in  Appendix  B.  There  are  80  overlaps,  including 
most  of  the  "core"  Lisp  func±ions.  The  similarity  is  0.18.  It 
is  interesting  to  note  tnat  tne  similarity  computed  by  tne  same 
measure  between  CSBGL  and  Ada  is  0.32  (Eeustman,  1982) .  Sc  tne 
keyword  similarity  between  two  diale<±s  of  tne  same  language  can 
actually  be  less  tnan  tnat  between  two  distinct  languages. 


Estimate  ql  Conversion  Effort 

The  formulas  given  in  Boehm  were  used  to  estimate  tne 
conversion  effort  required  tor  a  full  conversion  of  Loglisp  to 
tne  mLISP  system.  The  Loglisp  ^stem  contains  approximately 
2,000  lines  of  code,  as  formatted  ny  tne  pretty-printer.  The 
factors  uN  and  IM  are  estimated  at  30%  to  aiiow  for  tne  change  in 
tne  ^stem  environnent  and  funcn:ion  definition  mechanism  as  well 
as  tne  more  straightforward  changes.  CM  is  estimated  at  50%. 
Witn  tnese  figures,  ES6I  is  estimated  at  720  ana  conversion 
effort  in  man-months  at  1.7.  The  tape  conversion  required  about 
0.25  m  (Franson  and  Haslup,  1981),  emd  tne  conversion  of  a 
minimal  core  system  required  about  0.5  MM. 

Of  course,  these  figures  provide  cxiLy  a  very  rough  estimate 
or  conversion  effort.  They  were  develqped  based  on  ej^rienoe 
witn  systems  written  in  otner  languages,  and  it  is  not  at  all 
clear  now  well  they  s^iply  to  Li^.  Since  {xrogranming  in  Lisp  is 
more  complicated  tnan  progranming  in  OOBCL  or  FORIPAM,  it  is 
likely  tnat  tnese  formulas  will  underestimate  tne  effort 


required.  Also,  the  conoepc  of  "line  ot  oode”  is  not  as  well 
ctetined  for  Lisp  as  it  is  tor  many  otner  languages  since  programs 
are  not  divided  into  statements  in  tne  same  way  as  ror  many 
languages.  Ihe  approximation  used  here  was  to  suiid.y  use  tne 
lines  ot  text  provided  ty  tne  prettypr inter;  however,  tne  line 
breaks  could  have  been  done  in  mai^  different  ways.  It  would  be 
hi^y  desirable  to  have  a  working  definition  ot  source 
instruction  tor  Lisp  that  could  be  used  in  ouch  estimaticxis  and 
to  nave  data  validating  their  use  in  a  Lisp  enviroment. 
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FILE  CSGANIZATIOMS  FOR  LOGIC  FBOGRAIfftING 


Tnirftriiirt-ion 

The  clauses  m  a  xogic  program  can  be  divided  into  tne  two 
categories  ot  rules  and  facts.  A  fact  is  defined  here  as  a 
clause  with  no  body  and  no  variables.  A  query  is  a  clause 
containing  only  a  bo^.  All  otner  clauses  are  rules.  So  a  tact 
will  be  at  tne  end  ot  an  inference  patn  and  win  not  lead  to 
turtner  steps.  A  rule  contains  eitner  variaoies  or  inrerenoes 
(or  t»tn)  2uid  can  lead  to  a  turtner  unirication  step.  This 
^vision  follows  tnat  made  by  Klanr  (1979)  and  corresponds 
cioueiy  to  similar  (but  not  necessarily  identical)  distinctions 
made  ty  otners  (e.g.  unit  and  non-unit  clauses,  ground  ana  non¬ 
ground  clauses,  extensionai  data  base  ana  intensionai  data  base, 
assertions  euid  implications.) 

Searching  in  logic  based  ^stens  can  tnus  be  broken  down 
into  two  distinguishable  but  related  searching  problems:  rule 
selection  and  fact  retrieval.  Rule  selection  involves  tne  choice 
ot  tne  next  clause  or  go2LL  to  use  in  the  inference  process.  Fact 
retrieval  involves  locating  a  particular  clause.  However,  the 
distinction  is  not  absolute.  Located  tacts  are  used  in  tne 
inference  {Hrooess,  and  selecting  rules  involves  finding  tnem  as 
well.  Fact  retrieval  is  generally  discussed  witnin  tne  context 
ot  tne  retrieval  paradigm  used  in  tne  database  area;  overviews 
are  provided  in  Knutn  (1977)  ana  Wiederhoid  (1977) .  Rule 
selection  tedls  witnin  the  heuristic  search  paradigm  used  in 
artificial  intelligence.  in  most  current  work,  tnese  two 
searching  problems  are  kept  separate;  this  ap{xoach  appears  to  be 
more  etticient  tnan  intermixing  tnem. 


2^  nafaihaae 

The  relative  inportanoe  ot  rule  selection  ana  tact  retrievaj. 
oepenos  in  large  part  on  tne  application.  Some  applications, 
such  as  database  systoos,  have  relatively  tew  rules.  Others, 
such  as  theorem  proving  ^sterns,  have  relatively  more  rules. 
Since  searching  problems  in  unrestricted  resoiuticxis  interns  are 
not  yet  well  understood,  it  is  reasonable  to  consider  only  a 
subset  of  such  problems.  One  way  to  narrow  tne  problem  is  to 
consider  application  areas  ot  interest  to  see  what  tne 
Implications  ot  tneir  specitic  characteristics  are  tor  search 
strategies. 

Z3atabase  iqpplications  are  considered  here  since  use  ot 
artificial  intelligence  technic[ue8  can  provide  databases  witn 
more  flexibility  tnan  is  possible  in  current  oomnerciai  Etystems. 
A  possible  definition  of  an  intelligent  data  base  is  tnat  it  is  a 
database  from  which  incdicit  information  wnich  is  not  explicitly 
stored  can  be  retrieve.  One  well-studied  class  of  such 
databases  allows  tne  use  ot  logical  inferoioe.  Such  inferential 
databases  are  discussed  in  Galiaire  and  Minker  (1976) ,  Klahr 
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(1979) ,  and  Hinker  (1978) .  (It  is  possible  to  have  otner  t^pes 
ot  inference,  e.g.  statistical.) 

Some  the  characteristics  to  be  eaqpected  of  an  inferential 
database  based  on  logic  {vinciples  are 

a.  Low  ratio  of  rules  to  facts 

b.  Low  level  of  most  proofs 

c.  Possible  need  for  best  match  and  range  searches 

d.  Ri^id  response  for  interactive  use 

e.  Possible  need  for  extensive  updating 

f.  Potentially  very  large  size 

g.  Varying  degrees  of  data  accuracy  and  timeliness 

h.  Not  ail  relevant  data  included  (open  world  asscn{>tion) 

These  characteristics  are  not  necessarily  found  in  other 
logic  application  aras.  For  example,  none  are  likely  to  be  true 
Of  theorem  proving  applications.  These  factors  influence  tne 
acceptable  searching  strategies. 


liiinttfltagnfi  as.  Hashinn 

C  ''rent  artificieu.  intelligence  systems  depend  heavuy  on 
hashing.  When  it  is  feasible,  hashing  is  extremeiy  fast  and  is 
Often  the  method  of  choice.  This  reliance  ipcrn  hashing  has 
allowed  researchers  to  ooix^ntrate  on  tne  proolem  structure  and 
heuristic  search  without  getting  bogged  down  in  the  details  of 
fact  retrieval.  And  this  sppcoach  he£  not  created  any  prooiems 
in  tne  relatively  snail  in-core  ^stenus  predonunant  in  artificial 
intelligence  work.  However,  hashing  has  some  limitations  which 
rosy  cause  problems  in  such  systems;  tnse  involve  update  problems, 
best  match  and  range  searching,  and  locality  of  reference. 

Hsish  indices  degenerate  unoer  update  to  a  greater  extent 
tnsu)  many  otner  index  systems  (e.g. ,  B-trees) .  This  requires 
more  garbage  oollecticxi  and  possible  renasning.  Whiie  tne 
pointer  chasing  involved  in  Lisp  garbage  collection  does  not 
present  a  proUem  in  in-core  systems,  it  may  in  systems  tnat 
involve  storage  over  seversu  levels  of  memory  hiersircty. 

A  second  problem  is  tnat,  unless  tne  nasn  function  used  is 
order  preserving,  it  is  very  hard  to  handle  situations  involving 
best  match  or  range  searches.  The  respond  to  such  a  request,  tne 
system  is  reduced  to  hashing  on  aii  possible  values  tnat  might 
fail  witnin  the  desired  range  or  to  a  sequential  sesurch.  Index 
techniques  which  preserve  order  information  are  much  better  able 
to  handle  such  questions. 
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MBnagenent  of  a  meniory  hierarctiy  is  far  more  effective  when 
there  is  a  hic^  degree  of  locality  of  retet&Kx.  This  allows  tne 
I/O  overhead  to  oe  ^ead  over  a  greater  nunber  of  accesses, 
large  cystens  will  presanahly  depend  on  tne  use  of  a  memory 
hierarchy  and  will  need  to  use  storage  techniques  which  preserve 
locality  of  reference. 

It  would  be  desirable  to  esqdoit  tne  advantages  of  nasning 
even  in  a  much  larger  system.  However,  mechanisms  %miGh  preserve 
order  and  locality  will  be  required. 


Choice  File  Organizatimi 

Almost  all  of  the  work  on  selection  of  file  organizations 
has  focused  on  situations  in  which  tne  workload  to  be  namdled  is 
both  precisely  known  and  stable.  Under  tnose  conditions,  there 
are  many  aigoritnms  know  which  can  be  used  to  determine  optimaj. 
fixe  organizations  anchor  parameters.  However,  these  approaches 
sure  not  necessarily  as  useful  Mhem  tne  workload  is  neitner 
precisely  known  or  stable,  sis  is  to  be  eiqpected  in  an  intelligent 
database. 

In  such  a  context  only  partial  information  wui  be  available 
about  tne  classes  and  frequencies  of  queries  which  wul  be  posed 
to  tne  ^stem,  the  fields  which  wul  be  used  in  queries,  and  tne 
frequencies  witn  which  tnose  fields  win  be  used.  Hie  relative 
i]i|)ortanoe  of  uqpdate  and  retrievsu  is  slLso  unlikely  to  be  known 
precisely. 

Consider  a  ground  relation  wnich  has  five  possible  fields 
Which  could  be  used  for  indexing.  If  tne  frequencies  witn  which 
the  different  ccmbinations  of  fields  will  be  used  in  retrieval 
and  update  are  known,  it  is  possible  to  determine  a  reascxiable 
solution  to  tne  problem  of  determining  wmcn  or  tne  fields  snould 
be  indexed  (e.g.  Anderson  ana  Berra,  1977) . 

However,  if  little  is  known  about  tne  workload  that  tne 
Eystem  wui  neuidle,  such  algorithms  are  not  directly  applicable. 
Hiey  nust  be  suppLtanented  by  otner  approaches,  wiach  might 
include  worklad  sait|iling,  risk  analysis,  statistical  analysis, 
possibili^  theory,  and  eiqpert  systems.  The  system  can  maintaun 
statistics  on  requests  posed  over  tune  in  order  to  estimate  tne 
workload  at  a  given  tune.  This  information  can  be  used  to  select 
an  optimal  or  near  optimal  configuration  based  on  this 
information.  However,  this  may  not  be  adequate  if  tne  workload 
is  hi^y  variable.  The  use  of  logic  procedures  to  analyze 
useage  data  and  determine  appropriate  storage  organizations  is 
omsistoit  with  tne  goal  of  an  integrated  logic  0ystem. 

It  will  be  difficult  to  extend  tne  size  of  current 
inteiiient  systems  by  one  or  more  orders  of  magnitude  witnout  tue 
use  or  different  hardware  architectures.  The  are  two  mam 
directions  in  this  architectural  work:  tne  use  or  multiple 


pcooe880c8  and  the  use  of  oontmt  addreaaabie  (or  associative) 
storage.  Noltiple  processors,  which  oould  be  in  a  distributed 
could  be  used  to  explore,  in  paraiiiei,  alternate  patns 
tnrou^  tne  search  qpaoe.  Associatie  storage  can  be  used  for 
fast  retrieval.  (Schrag  1981)  describes  a  possible 
architecture  tor  handling  logic  database  applications.  Evoi  ir  a 
ocB{)uter  ardiitecture  well  adapted  to  tnese  types  or  applications 
is  used,  it  will  still  need  to  be  used  ettectively.  So  storage 
organizations  wui  contiue  to  be  a  problem  even  thou^  tne 
problem  parameters  wui  change. 
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A  I/3GZC  DESIGN  FOR  A  DOCUMENT  REOSaEUAL  EAXiffiASE 


1.  mfonnat-inn  itetricwai 

The  term  intomatiCHi  retrievaj.  is  widely  used  in  botn  a 
broad  sense  and  a  narrow  sense.  In  its  narrower  meeming,  an 
information  retrieval  ^stem  is  a  reterenoe  retrieval  system.  It 
is  tbis  use  which  will  be  considered  here.  Such  Gystems  provide 
lists  of  reterenoes  to  doctnents  in  response  to  user  gueries 
oasea  on  topics,  authors,  dates  or  publication,  and  similar  types 
or  information.  Information  retrievcu  systems  ditrer  from 
database  management  systems  tor  formatted  data  in  tneir  empnasis 
on  textual  data. 

The  index  terms  used  to  retrieve  tne  documents  my  be  chosen 
from  a  carefully  controlled  tt^saurus  of  allowed  terms.  Or  the 
uqportant  words  from  the  title,  the  abstract,  or  the  entire  text 
may  oe  used  in  a  less  controlled  situation.  Normalization  to  a 
standard  form  is  generauiy  allowed  in  order  to  eliminate 
vauriation  caused  by  pluraus,  verb  endings,  and  ocner  suffixes. 
In  current  ocoinercial  systems,  boolean  combinations  or  index 
terms  are  generaaiy  used  in  queries.  More  elaborate  mtching 
functions  have  been  used  in  experimentaa  systems,  and  research 
indicates  that  they  mig^t  be  more  effective  tnan  oonventionau 
boolean  mtching. 

Informtion  retrieval  systems  are  in  oomon  use  today.  They 
range  from  extensive  oomercial  services,  such  as  LocXheed's 
t^IALOG  system,  which  provide  access  to  dozens  of  different 
dataUsases  (collections  of  docunents)  to  small  systems  intended 
tor  personal  use  to  experimental  ^sterns.  An  introduction  to 
informtion  retrieval  systems  ray  be  found  in  Sedton  ana  McGill 
(1983) . 

Evaluation  of  informtion  retrieval  ^sterns  is  based  on 
peformance  effectiveness  as  well  as  efficiency.  The  response  to 
a  query  for  documents  on  a  particnilar  topic  will  generally 
include  some  items  which  are  not  relevant  to  tne  query  and  fan 
to  include  some  items  which  are  relevant.  The  extent  of  such 
failures  is  measured  by  recall  and  precision.  Recall  is  defined 
as  tae  fraction  of  the  relevant  docunents  wnich  are  retrieved. 
Precision  is  defined  as  the  fraction  c^  the  retrieved  docunents 
wnich  actually  are  relevant. 


2^  natataapB  jopiaBeDtad  id  iDgic 

Extensive  work  has  been  performed  on  tne  application  of 
logic  to  databases.  The  volune  edited  by  Gailaire  and  ninker 
(1978)  contains  mary  primriiy  theoretical  papers  on  tne  subject. 
Dahl  (1982)  describes  a  database  application  witn  a  Spanish 
language  interface  which  was  iaplemented  in  Prolog.  The  exanple 
appLlcetlon  is  a  anali  employee  database. 
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To  describe  a  database,  Dahi  ues  dcxnain  detiiutions,  which 
also  include  hierarchical  relationships,  relation  declarations, 
to  serve  as  relation  testates,  and  relation  detinitions,  which 
include  the  actued.  data.  Oo^o  (1979)  describes  an  adaptation 
ot  this  approach  to  Portuguese. 


1,.  Basic  Features  ot  an  IR  System 

Documents  in  eui  information  retrieval  system  need  to  be 
described  by  their  contents  and  by  tne  appropriate  bibliographic 
informatKMi.  A  possioie  set  of  relation  declarations  tor  cnis 
information  is 

title  (docunent  title) 

author  (document  author  order) 

date  (dociment  publication-date) 

publisher  (docunent  puDlisher) 

topic  (docunent  concept) 

The  first  four  relations  (tiue,  author,  date,  and 
publisher)  provide  the  basic  bibliographic  information  tor  tne 
docunent.  Here  it  is  assuned  that,  for  a  given  document,  tnere 
IS  only  one  title,  one  publication  dace,  ana  one  puDlisher. 
There  may  however,  be  more  that  one  author.  The  order  is 
preserved  for  an  author  so  tnat  it  is  possible  to  tell  tne  order 
in  wnch  tne  authors  were  listed. 

The  dunam  for  docunent  is  assuned  to  be  a  set  of  unique 
docunent  identifiers.  It  is  not  possible  to  reliably  identify  a 
docunent  ty  author,  by  title,  by  publisher,  or  even  by  date;  so  a 
unique  identifier  is  required,  (The  need  for  unique  identifier 
for  tne  various  entities  about  wnich  information  is  stored  has 
been  glossed  over  m  work  on  logic  databases.) 

A  document  mey  oontam  information  about  nany  topics,  and  a 
topic  may  be  discussed  m  many  documemts.  it  is  possible  to 
obtain  zai  the  topics  oontamed  in  a  docunent  or  eui  tne 
docunents  discussing  a  topic  by  posing  the  symmetric  queries: 

<-  topic  (docunent  x) 

<-  topic  (X  concept) 

Where  either  a  specific  docunent  or  a  specific  concept  is 
indicated. 

A  bibliographic  description  of  a  docunent  may  be  defined 
using 
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description  (u  v  w  x)  <-  title  (u  v) , 

publlBher  (u  w) , 
date  (u  X) 


<-  auttx>r  (docunent  x  y) 

<-  description  (docwent  v  w  x) 

usually  a  ocsibinacKMi  or  topics  is  speciiied  in  a  query 
rather  than  a  single  topic.  Boolean  queries  invoviing  tne 
operators  MD  and  OR  oouid  oe  readily  handled  using  the  Loglisp 
b^ean  operators  or  other  extraiogical  teatures  to  avoid 
r^tition  in  query  specitication. 


other  Beaturea 

Retrieval  perromanoe  can  he  enhanced  by  tne  use  or  Gtynorym 
information.  Even  it  one  term  is  used  in  a  query,  docunents 
ciassitied  witn  eynorvns  of  that  term  can  be  retrieved.  This 
teature  could  be  handled  by  the  tolloiiring  ground  relation 

synoivin  (wordl  word2) 

and  the  following  rules 

synonym  (x  y)  <-  syncx^ym  (y  x) 

synonym  (x  y)  <-  synonym  (x  z) ,  synonym  (z  y) 

topic  (docunent  x)  <-  topic  (docunent  y) ,  synonym  (x  y) 

A  more  elaborate  thesaurus  could  be  inplonented  to  handle 
hierarchical  reiationsnips. 

Oonoept  weights  are  frequently  used  in  order  to  indicate  tne 
relative  uportanoe  or  topics  oiscussed  in  docunent.  Such 
oonc^  weights  could  be  handled  by  using  an  expanded  ground 
reiatiOT 


tcpic  (docunent  concept  weight) 

A  query  which  request  docuneits  which  are  about  a  ^)ecitic  topic 
can  then  qpecify  a  cutorr  weight 

<-  topic  (docunent  concept  x) ,  greater  (x  cutott) 

Since,  in  most  aystsms,  concepts  wxtn  zero  weights  are  uniikeiy 
to  be  explicitly  ottered,  testing  tne  weight  to  see  iz  it  is 
greater  than  zero  should  be  unneoessary. 

Jtsrs  is  sons  evidenoe  that  retrieval  pertormanoe  can  oe 
enhanced  by  using  mat^iing  functions  otnsr  tnan  supie  boolean 
natchig.  Suggestions  include  tne  use  oc  similarity  functions 
based  on  vector  modals  of  docunents  ana  queries  and  tne  use  or 
tussy  set  tneory.  Such  nmasures  could  be  hifilflaKnted  in  logic 


but  ml^t  be  more  easily  infilanented  in  extreLLogiced  features 
sucb  as  those  available  in  Loglisp. 

The  dosed  world  assuDoption  tnat  aii  relevant  information  is 
present  in  the  knowledge  base  is  not  viable  in  information 
retrieval  systems.  It  is  generally  accepted  tnat  a  documoit 
ney  contain  information  about  a  concept  even  tnough  tnat  concept 
has  not  been  used  to  index  it.  OSius  failure  can  not  be 
interpreted  as  negation. 
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INDEX  TO  THE  ALISP  VEeBSWCE  MANUAL 


ALISP  mxx 


*  48 

absval  108 
addPil  102 
adcigt  90 
addlt  90 
addl  108 
and  76 
append  96 
apply  54 
apply*  54 
argn  59 
array  116 
arrayp  117 
arrayl  116 
arrtype  117 
ascii  149 
atxength  39 
atnhash  33 

backprn  120 
backtrk  119 
bnum  116 
break  131 

c....r  95 

car  95 
cars  95 
cdr  95 
cdrs  95 
close  146 
clrbit  111 
oomuent  170 
conpile  199 
cone  97 
concons  96 
cond  75 
cons  96 
copy  98 
oops^Ue  168 
cos  109 
cshltt  110 

doopy  98 
de  63 

deefile  174 
detprqp  93 
delete!  102 
d£  63 
diff  107 

Alma  117 

dispose  147 
divide  107 
do  79 
dooons  81 
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echo  11,150 
edit  178 
ettaoe  102 
entry  138 
eofnark  153 
eotskip  153 
eofstat  152 
eoxi.  9 
eoiw  25 
eq  83 
eqp  84 
eqs  114 
equal  88 
err  124 
errprin  120 
errset  121 
esnict  110 
eveU.  45,53 
evalquote  45 
exit  49,138 
exp  109 

filestat  145 
fix  106 
fixp  106 
flanbda  57 
float  107 
fioatp  106 
fntype  65 
frunno  145 
fuzz  86 

gc  14 
genchar  7 
gensym  37 
get  93 
gettun  65 
getval  42 
go  77 

greaterp  87 
griixj  168 
gts  114 

haitpri  30 
hprnun  30 
hw  116 

if  7 

illegal  40 
inbase  15 
InltfUe  164 
input  164 
intadd  90 
Intern  115 
inunit  9 
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label  60 
lambda  57 
l£^  204 
last  95 
length  95 
lessp  87 
list  96 
listtuie  168 
litp  36 
Invin  116 
load  154 
log  109 
logand  110 
logical  107 
lognot  110 
logp  106 
logor  110 
logxor  110 
Its  114 
local  147 

mapc  71 
napcar  71 
mapoon  71 
mapconc  71 
mapl  71 
ma^ist  71 
max  87 
menb  83 
laenber  8 
min  87 
minus  108 
minusp  87 

nconc  101 
ml  37 
normtab  152 
null  37 
nunbecp  106 

oblxst  33 
oddp  87 
open  144 
or  76 
outbese  16 
output  165 
outputs  165 
outumt  24 

pack  39 
packl  32 
pagetiie  2 
paramti  141 
paramgc  141 
paramti  125 
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plist  34,42,93 
plus  107 
plu^  87 
ppcine  177 
pprint  177 
pr  mar  ray  117 
prmb  32 
farmbeg  70 
prinend  24,30 
prinlen  30 
print  25 
prinl  30 
prog  77 
progn  79 
praqpt  10 
prop  93 
purge 

purgfiie  167 
put  93 

gsetq  40 
quotient  107 

randy  lio 
read  12 
readarray  117 
reaidieg  22 
readch  23 
readend  22 
readent  22 
readlen  22 
rea<kiD  2 
rea^  23 
reac^  23 
remainder  12 
remob  34 
tafvop  93 
rq)eat  81 
return  77 
reverse  99 
rewind  152 
rpiaca  100 
rplacd  100 
runtime  126 

save  154 
seiectq  76 
set  40 
setblt  111 
setq  40 
sin  109 
slasbee  152 
qmcial  33 
sgrt  109 
status  13 
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strcars  113 
strcdrs  113 
strcxinc  114 
strtina  114 
stxtest  114 
SUDl  108 
eys  45 
s^sin  47 
sysprin  48 
Eysout  47 

teread  22 
teipci  25 
tunes  107 
togbit  111 
trace  135 
tracflg  135 
tstbit  111 
ttychar  11 

unitnoe  145 
unpactc  39 
untrace  135 

vaiuep  42 

Wipe  34 
wipelist  34 

zerop  87 
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i 
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ua  LISP 


ALISP 


ttu 

abaval 

aooa  (u) 
addl 

addgt 

addlt 

aliBt 

and 

and 

anc^  (u) 

append 

apply 

append 

apply 

apply* 

apply-  (u) 
arg 

ar^i 

array 

array 

arrayl 

aacii 

asm 

a8aoc(u) 

arrayp 

arrtype 

aacii 

aaso^i  (u) 

atan  (u) 

atlength 

atntiaan 

aton 

naciqprn 

backtrk 

bakgag 

baae 

blgmm 

bnun 

boole 

bptftd 

bporg 
break 
braakl  (u) 

break 

braakd  (u) 
breakexp  (u) 

breakin  (u) 
breaknacroa  (u) 
brokenfna  (u) 

c«  < « *r 

c«  • • • r 

car 

car 

oara 

odr 

cdr 

Odra 

chrct 
chrvai  (u) 

cloae 

clrbfl  (u) 
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cxMfons 


oono 

cxms 

oon^  (u) 
ooiy  (u) 

008  (u) 
ooad  (u) 
ooati  (u) 
csym 


clrbit 

oomnent 

compile 

cone 

OCHfKXtnS 

oonO 

cons 

oofy 

ooiyfue 

006 


cstiitt 


6oo[V 

dot  (u) 
ddtin 
dettout 
de 

decfiie 

detprop  detprop 

deletei 

deposit 

d£  df 

dift 

ditterenoe 

dins 

dispose 

divide  divide 

dn 

do 

dooons 

drenove  (u) 
deeverae  (u) 
dem  (u) 
dsicin  (u7) 
dskout  (u) 
dsn  (u) 
dsubet  (u) 


ditterenoe 

ditt 


echo 

ed 

edfun 

edit 

editooBiBl  (u) 
•dltdetault  (u) 
edits  (u) 
editt  (u) 
edltfindp  (u) 
edltfns  (u) 
edlttpet  (u) 
ediU  (u) 
editp  (u) 
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editraoetn  (u) 
editv  (u) 
edi^e  (u) 

ettaoe 

entry 

eotnak 

eotskip 

eotstat 

eoxr 

eoiw 

eq  eq 


eqp 

eqs 


equal 

equal 

err 

err 

erri^xn 

error  (u) 
errae  (u) 
errset 

errset 

esnitt 

eval 

eval 

evalquote 

evaiv  (u) 
examine 

exarray 

excise 

exit 

exp  (u) 

ei^odec 

exp 

expr 

texpr 

tiiein 

txienames 

tuestat 

tix 

tix 

tuqp 

fixla 

fixiuin 

fiantxia 

tiatsize 
tlatsizec 
float  (u) 

(u) 

float 

fioatp 

tionvia 

toroe 

tixiMckpt  (u) 

fntype 

free  (u) 
freelist 

(u) 

frunno 

fsutM: 

tunarg 

function 
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ALISP 

functi-CHiaLL 

tuzz 

gc 

gc 

god 

gcgag 

gctime 

genchar 

gen^ym 

get 

getiun 

getval 

go 

go 

greaterp 

greaterp 

grind 

grindet 
grinl  (u) 
grinc^ope  (u) 

gts 

hairpri 

hghcor  (u) 

(u) 

hihorg  (u) 

hprnun 

hw 

ibase 

identifier 

It 

Illegal 

inbaae 

inc 

initfxie 

initfn 

initproRf)  (u) 
input 

input 

intadd 

integer 

intern 

intern 

inunxt 

label 

label 

lanMa 

lambda 

1^  (u) 

lap 

laplst  (u) 
last 

lastword  (u) 
lastpos  (u) 
loonc  (u) 

last 

Idiff  (u) 
length 

length 

lessp 

lexorder  (u) 
leiqpr 

lesqp 
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COmEKCS 


lineiength 
linereiM3  (u) 
liat 

litatom  (u) 


load 
log  (u) 


list 

listfixe 

litp 

Inun 

load 

log 

logand 

logical 

logo 

logor 

logxor 


boole 


boole 

boole 


Isb 

Isubr 
isubet  (u) 

Its 

macro 

maknam 

maknum 

map 

mapc 

m^nan  (u) 

mapc 

luqpcar 

mapear 

mapoon  (u) 

mapoon 

nopconc  (u) 

mapoonc 

mapl 

insist 

roaplist 

max  (u) 
maxlevel  (u) 

max 

mod)  (u) 

menfaer 
madaer*  (u) 

menter 

(u) 

mm  (u) 

mm 

minus 

rnmus 

mmu^ 
modcnar  (u) 

mmuap 

noonc 

noonc 

neons 

noons 

neg  (u) 
nextev  (u) 
nU 

nill  (u) 

nil 

nooall  (u) 

noemtab 

not 
nouuo 
neo  (u) 
ntndiar  (u) 
null 

null 

ditterent  parameter  order 
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nuntet 

nunterp 

nuBvai 

okxList 


or 

or-  (u) 

outc 

output 


outvai  (u) 


paton  (u) 
pgiine 

plus 

pname 


prevev  (u) 
prinl 


prxnc 


print 

printiev  (u) 
prog 

progl  (u) 
prog2 
progn 
proni>t  (u) 


putprqp 

put^ 


quote 

quotient 
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nunberp 

oblist 

ocidp 

open 

or 

outbase 

output 

outputs 

outunic 


pack 

packl 

pagetue 

paramti 

paramgc 

parantci 


plist 

plus 

plusp 

pprine 

pprint 

prinl 

prinarray 

pcinb 

prinbeg 

prinend 

prinlen 

lerint 

prog 


progn 

pronpt 

prop 

purge 

pursue 

put 


qsetq 

quotient 
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ua  LISP 


MilSP 


CSMIBIIS 


randan  (u) 

randy 

read 

read 

readarray 

readbeg 

readcti 

readch 

readend 

readout 

readien 

readlist 

rezKkip 

reactm 

read^  (u) 

read^ 

ree  (u) 
remainder 

remainder 

resiob 
remove  (u) 

remob 

renprop 

raiprop 

repeat 

reset 

recrrom  (u) 
return 

return 

reverse 

reverse 

rewind 

rplaca 

rplaca 

rid.aod 

rplaod 

runtime 

sassoc 

save 

seiectq  (u) 

seiectq 

set 

setarg 

set 

setoit 

setchr  (u) 

setq 

sin  (u) 

Sind  (u) 

sin 

Sinn  (u) 

slashes 

speaK 
specbind 
special  (u) 
specstr 

special 

qpdlic  (u) 
spdlpt  (u) 
apdirt  (u) 
^edo  (u) 
qpcevai  (u) 
^icint 
■9rt  (u) 

sqrt 

status 

stkcxMint  (u) 
stknams  (u) 
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rand^ 

raiKto 


uses  eq 
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ALISP 

OOMNE^ 

stkntn  (u) 

stkprt  (u) 
stksrch  (u) 

store 

strcars 

strcdrs 

stroonc 

strtind 

stnngp  (u) 

strtest 

SUDl 

suolis  (u] 
sui^ir  (u) 

suol 

subr 

subst 

&ys 

sysclr  (u) 

sysin 

^sprin 

sysout 

t 

tab  (u) 
taiip  (u) 
tan  (u) 
tanti  (u) 
toonc  (u) 

teread 

terpri 

terpri 

tune 

tunes 

tunes 

togbit 

trace 

traoedfns  (u) 

trace 

traoet 

tracflg 

tstbit 

ttycbar 

ttyecho  (u) 

tyi 

tyo 

unbound  (u) 
unbreak  (u) 
undolst  (u) 
unflnd  (u) 

unitnos 

unpack 

untraoe  (u) 
untyi  (u) 

untrace 

i^indO-g  (u) 

valuep 

wipe 
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wipelist 

xcons 

zerop  zerop 

$eof$ 

* 

*ainake 

^append 

»dit 

*e]q>anci 
ei^iandl 
♦function 
♦getsym 
•great 
♦Icail 
♦less 
♦max  (u) 

♦min  (u) 

♦nopoint 

♦plus 

♦^tsym 

♦quo 


